[Previous] [Next] [Index] [Thread]

Re: _DNS_ security problems

Two issues:

1) In the bind-4.9.3 (beta something) distribution, in the file
SunSecurity, it is mentioned that:

--------------------------------------------------------------------
The C library shipped with SunOS 4.1.3 (and perhaps earlier and later
versions) has some added "security code" inside of gethostbyaddr().
This code consists of doing a gethostbyname() on the result of a
gethostbyaddr(), and then checking to see if one of the addresses
returned by gethostbyname() matches the original argument to
gethostbyaddr().  In other words, it checks to see that a host has both
a PTR record, and a matching A record.

If you remove the Sun-supplied gethostbyaddr(), and replace it with the
one provided by BIND 4.9.2, and you want the same behavior, then I
believe the SUNSECURITY #ifdef is necessary.  If you want a less "fussy"
gethostbyaddr(), then leaving it out is OK.
--------------------------------------------------------------------

...naturally, one cannot assume this is true for all gethostbyaddr()'s,
but this sets a good precedent.  I'm not convinced that such
functionality belongs in gethostbyaddr(), but I do believe there should
at least be a function (if there isn't already, I don't work with this
stuff frequently) in the standard bind distribution, that does precisely
this (independent of your chosen #ifdef's).

2) Additionally, (and perhaps more importantly) purdue-thesis.ps, in
that same distribution, discusses advertising bogus PTR's, in addition
to bogus A's.  The mechanisms of such advertising is discussed in a
somewhat hand-waving manner.  From pages 42 and 43:

--------------------------------------------------------------------
3.4.3 The "Cache Poisoning" Approach

In this approach the "rlogind" daemon tries to enhance security by
calling the function "gethostbyname()" to verify the mapping from
IP(H(b)) to H(a).  The attacker however has a way of subverting this
additional security feature.  He can send the additional mapping of H(a)
to IP(H(b)) along with the answer to the query IP(H(b)).  By the time
the daemon calls "gethostbyname()," it already has the necessary mapping
information in its cache.  The daemon believes the cached data and again
grants the attacker access.
--------------------------------------------------------------------

EKR wrote:
> 
> Dan writes:
> >In this case, yes, a fix for this should be added to java, and if sun
> >chooses to do so, it should be commended for it, but that is only _because_
> >DNS is insecure. The DNS should still be fixed, it's just a longer-term,
> >(much) more time-consuming fix.  If there is no longer a list of what
> >addresses have been delegated where (ahhh shortsightedness!), an effort
> >to (re)build the information should be mounted; Ensure a hierarchy of
> >machines providing a canonical list (in distributed manner) of who can
> >legitimately advertise what addresses and names (covers A, CNAME, MX,
> >whatever), and check for validity when moving up the tree.  You can lie
> >about your own HINFO's if you want, in practice they aren't highly
> >accurate anyway.
> I did try to be clear about what the problem was, but it seems I
> wasn't clear enough. There _IS_ a list of backpointers from addresses
> to domain names. It's the in_addr.arpa domain. If Java checked
> that as well in order to do its verification, as say TCP Wrappers
> does, then this attack would be impossible (barring genuine
> DNS spoofing, which, as I said, will be stopped by DNSSec as
> it is already specified.
> 
> -Ekr
References: